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APPLICATION  OF  IMAGE  COMPRESSION 
TO  DIGITAL  MAP  DATABASES 


I.  INTRODUCTION 

The  Microprocessor  Technology  Utilization  Program  (RG-7)  exists  for  the 
purpose  of  examining  commercial  microprocessor  hardware  and  appl3dng  it  to 
developing  military  systems  prior  to  the  release  of  any  militarized  components. 
As  part  of  this  objective,  RG-7  is  looking  at  commercially  available  image 
compression  chips/ chipsets  that  might  serve  a  valuable  role  in  emerging 
military  systems.  Under  the  RG-7  program,  we  have  examined  still  image 
compression  chips/chipsets  and  their  potential  application  in  the  area  of 
digital  map  database  compression. 

As  imaging  needs  continue  to  grow,  techniques  are  needed  to  help 
control  the  vast  amounts  of  data  produced.  One  example  of  this  can  be  seen  in 
the  area  of  digitized  paper  maps.  A  single  1/50,000  scale  ARC  Digitized  Raster 
Graphics  (ADRG)  map  image  requires  approximately  373  Mb)rtes  of  memory  to 
represent  an  area  of  approximately  44Km  x  72Km.  This  memory  requirement 
is  clearly  overwhelming  to  all  but  the  largest  storage  media.  To  compound 
matters,  when  a  significant  area  of  coverage  is  required,  even  the  largest 
storage  media  are  ineffective.  Not  only  are  the  memory  requirements 
enormous,  transmission  of  images  this  large  would  require  extraordinarily  long 
periods  of  time  (4.5  days  @  9600  Baud).  In  order  to  reduce  this  massive 
storage  and  transmission  requirement,  this  study  examined  the  application  of 
still  image  compression  techniques  to  digitized  paper  map  data. 

II.  BACKGROUND 

Many  military  systems  may  soon  begin  to  require  the  use  of  digitized 
paper  maps  for  land  navigation  purposes.  Some  candidate  systems  may 
include  Multiple  Launch  Rocket  System  (MLRS),  Fiber-Optic  Guided  Missile 
(FOG-M),  Unmanned  Aerial  Vehicle  (UAV),  and  Unmanned  Ground  Vehicle 
(UGV).  In  this  study,  MLRS  was  the  system  targeted  for  implementing  a 
compressed  map  database.  When  fielded,  the  MLRS  Improved  Fire  Control 
System  (IFCS)  will  contain  a  militarized  300-Mbyte  hard  disk  for  all  system 
storage  requirements.  As  previously  stated,  this  will  not  even  allow  for  a  44Km 
X  72Km  area  of  coverage  of  digitized  paper  maps.  Clearly,  the  solution  is  to 
reduce  the  storage  size  of  the  digitized  paper  maps  while  retaining  high  visual 
quality. 

During  the  development  of  the  MLRS  IFCS,  a  Technical  Risk  Investigation 
System  (TRIS)  was  designed  to  investigate  problems  associated  with  current 
technology  limitations  and  explore  possible  solutions  to  these  problems.  As 
part  of  the  MLRS  TRIS,  the  use  of  compressed  digitized  paper  maps  was 
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studied.  This  study  looked  at  both  the  preprocessing  phase  (compression)  of 
digitized  paper  maps  as  well  as  the  decompression  and  display  of  these  maps. 
As  an  end  result  of  this  study,  it  is  hoped  that  lessons  learned  from  the  MLRS 
TRIS  can  be  applied  to  any  and  all  military  systems  requiring  digitized  paper 
map  data. 

III.  IMAGE  COMPRESSION  TECHNIQUES 

As  part  of  this  study,  four  types  of  image  compression  techniques  were 
examined  for  their  potential  use  in  digitized  paper  map  compression.  These 
image  compression  techniques  include  Joint  Photographic  Experts  Group 
(JPEG),  Px64,  Motion  Picture  Experis  Group  (MPEG),  and  Fractal  Compression. 
See  Table  1  for  a  brief  summary  of  each  compression  technique.  After  careful 
examination  of  each  data  compression  technique,  it  was  decided  that  JPEG 
would  be  used  to  implement  the  compressed  digitized  paper  map  study.  Two 
reasons  were  cited  for  this  decision:  (1)  JPEG  is  currently  in  the  balloting  phase 
of  becoming  an  international  Standard  (ISO/IEC  DIS  10918),  and  (2)  vendors 
are  currently  marketing  chips/chipsets  that  comply  with  the  JPEG  algorithm. 
At  the  time  of  this  study,  no  chips/ chipsets  were  found  that  implemented 
either  the  Px64  algorithm  or  MPEG  algorithm.  The  fractal  compression 
technique,  although  promising,  is  a  proprietary  algorithm  and  thus  not  an 
industry  standard. 


NAME  ' 

COMPRESSION 

ALGORfTHM 

INDUSTRY  STANDARD 

IMAGE  TYPE 

USEABLE 

RATIOS 

REALTIME 

COMP/DECOMP 

JPEG 

Dcr 

Balloting  phase 

Full  color;  Still  Images 

25:1 

Yes 

Px64 

DCT,  Predictive 
interframe  coding 

Yes 

Full  color;  Low  motion  level  video 
images 

100:1 

Yes 

MPEG 

DCT;  Interpolated 
interframe  coding 

Draft  phase 

Full  color;  Motion  intensive  video 
images 

200:1 

No-comprcssion 

Yes-decompression 

FRACTAL 

Fractal  Transform 

No 

Full  color;  Still  images  and  motion 
intensive  video  images 

76:1 

No-comprcssion 

Yes-decompression 

Table  1.  Image  Compression  Technique  Comparison 

rv.  JPEG  ALGORITHM 

The  JPEG  algorithm  is  a  Discrete  Cosine  Transform  (DCT)  based 
technique  that  is  primarily  used  for  continuous-tone  still  images.  The 
algorithm  itself  relies  heavily  on  reducing  redundant  visual  information 
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by  way  of  the  DCT  and  quantization  and  then  efficiently  encoding  the  data. 
Because  redundant  data  is  removed  during  the  JPEG  compression  process  and 
therefore  the  compressed  image  no  longer  exactly  matches  the  original  image, 
this  type  of  compression  technique  is  said  to  be  "lossy". 

The  sequence  of  events  that  occur  during  a  JPEG  compression  can  be 
seen  in  Figure  1 .  The  first  step  involves  performing  a  DCT  on  the  image 


Figure  1.  JPEG  Baseline  Compression 

data.  The  DCT  itself  is  used  to  transform  the  image  data  into  its  frequency 
coefficients.  Once  these  frequency  coefficients  have  been  isolated,  they  are 
then  quantized  in  order  to  reduce  the  range  of  possible  frequency  values.  The 
level  of  quantization  the  frequency  data  undergoes  is  known  as  the 
"quantization  factor".  The  quantization  factor  is  a  user  definable  value  and,  as 
will  be  discussed  later,  plays  a  significant  role  in  the  quality  of  a  compressed 
image  and  the  level  of  compression  attained.  The  quantization  phase  of  the 
compression  process  is  the  "lossy"  portion  of  the  JPEG  algorithm.  Entropy 
encoding  then  follows.  This  step  compresses  the  data  yet  again  but  it  does  so 
in  a  "lossless"  manner  (data  in  exactly  represents  data  out).  Data  that  occurs 
frequently  is  represented  using  shorter  codes  while  less  frequently  occurring 
data  is  represented  with  longer  codes.  The  output  from  the  encoding  phase 
represents  the  compressed  image. 

In  order  to  display  a  compressed  image,  it  must  first  be  decompressed. 
Because  of  the  nature  of  the  DCT  and  the  JPEG  standard,  the  sequence  needed 
for  decompression  is  simply  the  reverse  of  the  compression  process.  The 
decompression  sequence  is  illustrated  in  Figure  2.  The  compressed  image  is 
first  decoded,  an  inverse  quantization  is  then  performed,  and  finally  the  Inverse 
Discrete  Cosine  Transform  (IDCT)  is  used  to  convert  the  frequency  coefficients 
back  into  pixel  data. 
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The  JPEG  standard  was  written  so  as  to  perform  compression  on  image 
data  independent  of  the  color  space  of  the  data.  Vendors,  however,  have  added 
specialized  front  ends  to  their  chips/ chipsets  so  as  to  allow  the  user  to  easily 
compress  common  image  data  formats.  One  such  representation  of  image  data 
is  red,  green,  blue  (RGB).  Because  many  digital  image  databases  are 
represented  in  this  format,  it  was  necessary  for  vendors  to  develop  suitable 
front  ends  that  would  enable  compression  of  RGB  data.  The  most  common 
front  end  solution  to  compressing  RGB  data  is  to  convert  it  to  its  luminance 
and  chrominance  (YUV)  components.  This  is  done  by  performing  the  following 
linear  transformation  on  the  RGB  data: 


RGB-to-YUV  TRANSF0RMAT10N[2] 


Y  0,299  0.587  0.114  R 

U  =  -0.169  -0.3316  0.500  G 

V  0.500  -0.4186  -0.0813  B 

Upon  decompression,  the  inverse  of  the  above  matrix  is  used  to  go  from  YUV 
color  space  to  RGB.  Figure  3  shows  the  JPEG  baseline 

compression/decompression  algorithm  plus  extensions  provided  by  vendors  for 
handling  RGB  color  space  issues.  Color  spaces  other  than  RGB  that  vendors 
make  allowances  for  include  cyan,  magenta,  yellow,  black  (CMYK)  and  gray 
scale. 
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Figure  3,  JPEG  Baseline  Algorithm  Plus  Color  So^ce  Extension 

VI.  DATABASE  PREPROCESSING 

In  order  to  adequately  examine  digitized  paper  map  database 
compression/decompression,  a  suitable  database  had  to  be  selected  that  would 
comply  with  the  requirements  imposed  by  the  MLRS  IFCS.  The  database 
selected  was  1/50,000  scale  ADRG.  This  database  is  distributed  by  the 
Defense  Mapping  Agency  (DMA)  and  is  available  on  compact  disk  (CD-ROM). 
The  area  of  coverage  received  was  from  49®  00’ N  to  49®  24’N  longitude  and  11® 
OO’E  to  12®  OO’E  latitude  (part  of  what  was  formerly  West  Germany).  This 
digitized  paper  map  data  is  in  24-bit  RGB  format  and  requires  approximately 
373  Mbytes  of  space  on  the  CD-ROM. 

The  format  of  the  image  data  on  the  CD-ROM  required  that  the  data  be 
reformatted  prior  to  compressing  the  image.  As  shown  in  Figure  4  the  raw 
image  data  is  broken  down  into  128x128  pixel  tiles.  Each  of  these  tiles 
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Figure  4.  ADRG  Pixel  Tile  Arrangement 

represents  either  red  color  byte  information,  green  color  byte  information,  or 
blue  color  byte  information.  For  proper  compression,  the  image  data  must  be 
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in  a  sequential  RGB  format.  This  means  that  for  any  image  tile,  red  pixel^  y 
must  be  placed  next  to  green  pixel„y  which  should  be  adjacent  to  blue  pixel^^y. 
All  pixels  in  each  image  tile  are  arranged  in  this  RGB  manner  prior  to  any 
compression.  RGB-ordered  image  tiles  are  then  saved  to  a  hard  drive  to  await 
compression.  Code  that  was  generated  to  perform  this  reformatting  of  the 
ADRG  image  data  can  be  found  in  Appendix  A. 

Once  the  complete  ADRG  image  has  been  reformatted,  the  compression 
portion  of  the  database  preprocessing  sequence  can  begin.  This  sequence 
prompts  the  user  for  the  upper  left  longitudinal  and  latitudinal  coordinates  of 
the  image,  the  compressed  file  prefix,  and  the  quantization  factor  that  will  be 
used  in  compression  of  all  image  tiles.  Once  determined,  ail  image  tiles  will  be 
named  using  the  user  inputs  and  compressed  using  the  particular  quantization 
value.  The  quantization  factor  is  used  to  determine  the  level  of  redundancy 
eliminated  and  does  not  directly  represent  the  compression  ratio  that  will  be 
achieved.  Because  some  ADRG  image  tiles  will  contain  more  redundant  visual 
information  than  others,  the  compression  levels  between  tiles  will  differ.  After 
each  image  tile  has  been  compressed,  it  is  then  stored  on  the  MLRS  TRIS  hard 
drive  until  needed  for  display.  Figure  5  shows  the  entire  preprocessing 
sequence  as  performed  on  a  486  computer  equipped  with  a  CD-ROM. 


ADRG  128x128  PIXEL  128x128  PIXEL  COMPRESSED  TRIS 

DATA  TILES  TILE  TILE  HARD  DISK 


Figure  5.  ADRG  Database  Preprocessing 

VII.  DATABASE  DECOMPRESSION 

An  important  consideration  in  database  decompression  was  to  make  sure 
that  images  were  decompressed  quickly  so  as  to  not  create  huge  latency 
periods  during  data  updates.  From  Table  1  it  can  be  seen  that  JPEG  compliant 
chips/chipsets  will  perform  image  compression/decompression  in  "real-time”. 
This  means  that  images  can  be  compressed/ decompressed  at  video  rates  of  30 
frames  per  second.  This  claim  of  "real-time"  can  be  somewhat  misleading 
because  it  is  dependent  upon  the  resolution  and  quantization  level  of  the 
image.  An  image  with  less  resolution  can  be  compressed  at  a  lower 
quantization  level  (lower  compression  ratio;  better  visual  quality)  in  "real-time" 
while  an  image  with  a  higher  resolution  must  be  compressed  at  higher 
quantization  levels  (higher  compression  ratio;  poorer  visual  quality)  in  order  to 
be  "real-time".  A  second  point  must  also  be  made  about 

compression/ decompression  rates.  Even  though  compression/decompression 
may  occur  at  rates  of  30  frames  per  second,  one  must  still  transfer  data  to  and 
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from  the  compression/ decompression  card.  This  means  that  a  bottleneck  exits 
with  respect  to  transferring  data  to  and  from  a  hard  drive,  memory,  serial 
input/output  (I/O),  CD-ROM,  etc.  In  order  for  the  compression  chip/chipset  to 
achieve  maximum  compression /decompression  rates,  high  data  transfer  rates 
must  be  supported  and  this  is  sometimes  not  achievable  in  a  personal 
computer  (PC)  environment.  The  "real-time"  compression/decompression  claim 
of  JPEG  compliant  chip/ chipset  vendors  must  be  viewed  with  an 
understanding  of  the  end  goal  and  the  possible  limitations  of  the  target  system. 

With  this  in  mind,  we  remember  that  in  our  application  we  are  examining 
the  use  of  JPEG  to  compress/ decompress  digitized  paper  map  data  for  the 
purposes  of  land  navigation.  For  our  study,  this  task  does  not  need  to  be 
performed  in  "real-time".  A  vehicle  such  as  MLRS  is  not  overly  quick  and  will 
perhaps  sit  at  a  single  location  for  long  periods  of  time.  This  will  not  require 
high  update  rates  from  the  compressed  image  data.  Perhaps  the  only  time  that 
a  high  volume  of  data  will  be  required  for  decompression  and  display  will  be  at 
startup.  At  this  time,  an  initial  map  will  be  retrieved  from  memory, 
decompressed,  and  displayed.  After  that,  only  small  updates  will  be  required 
to  support  vehicle  movement,  etc.  The  "real-time"  decompression  and  update 
of  the  map  is  not  a  critical  issue.  The  decompression  and  display  of  the  map 
data  should  be  reasonably  quick  but  "real-time”  is  not  a  requirement. 

The  decompression  side  of  digitized  map  database  display  involves  three 
main  events.  These  three  events  include  map  tile  retrieval,  decompression,  and 
display.  Each  of  these  events  must  occur  in  a  manner  that  will  minimize  the 
overall  time  required  for  map  updates.  For  demonstration  purposes,  code  was 
generated  on  a  486  PC  that  retrieved,  decompressed,  and  displayed 
compressed  ADRG  data  (see  Appendix  A). 

Retrieval  of  map  involves  first  selecting  a  tile  or  multiple  tiles  for  display. 
This  might  involve  prompting  a  user  for  input  or  using  navigation  system  data 
to  select  map  data  for  display.  The  map  data  could  then  be  retrieved  from 
some  sort  of  storage  device  (hard  drive,  CD-ROM,  etc.).  For  demonstration 
purposes,  manual  input  of  a  map  tile  was  required.  Once  received,  adjacent 
tiles  (up  to  2  rows/2  columns  away)  were  determined.  This  produced  a  5x5 
matrix  of  map  tile  data  with  a  resolution  of  640x640  pixels  (height  =  5*128, 
width  =  5*128). 

Once  the  tiles  needed  for  display  were  determined,  decompression  of  the 
tiles  could  begin.  Tiles  were  retrieved  sequentially  starting  with  tilco  q  of  the 
5x5  matrix  and  ending  with  tile^  4.  Retrieval  and  decompression  of  each  tile 
required  less  than  .5  seconds  for  completion.  This  decompression  time 
resulted  from  tests  using  LEAD  Technology's  LEADVIEW  255  compression  card 
based  on  the  C-Cube  CL550  compression  processor  and  LEAD  Technology's 
LEADTOOLS  V2.3  software  run-time.  Again,  most  of  this  time  can  be 
attributed  to  hard  drive  accesses  and  data  transfers  across  the  PC  bus  rather 
than  the  actual  decompression  operation  itself. 
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As  Stated  earlier,  all  tiles  were  compressed  from  an  RGB  {24-bit  color) 
format.  Once  decompressed  the  tiles  needed  to  be  color  optimized  for  display. 
This  is  due  to  the  fact  that  Video  Graphics  Adapter  (VGA)  displays  only  support 
a  maximum  of  256  colors.  RGB  color  provides  up  to  a  maximum  of  16.7 
million  colors.  Color  optimization  was  used  to  select  the  best  256  colors 
needed  to  reproduce  each  image  tile.  Examining  this  a  little  further  reveals 
that  for  each  image  tile  there  exists  256  colors  that  will  best  represent  each  tile; 
however,  each  tile  may  not  optimize  to  the  same  256  colors.  This  means  that 
in  order  to  achieve  the  best  256  colors  for  the  entire  displayed  image  (5  tiles  x  5 
tiles),  the  color  palettes  for  each  tile  must  be  optimized  as  a  whole  in  order  to 
get  the  best  256  colors  that  represent  the  entire  image.  After  decompressing 
each  tile,  a  color  optimization  was  performed  on  the  tile.  The  optimized  tile 
palette  was  then  stored  in  a  file  containing  all  other  optimized  tile  palettes. 

After  completing  the  optimization  on  all  25  tiles,  the  optimized  palette  file  was 
then  itself  optimized  to  256  colors.  This  color  optimization  produced  the 
"image  palette". 

Display  of  the  map  tiles  involved  indexing  all  8-bit  pixel  color  values  from 
each  tile  into  the  "image  palette".  All  image  tiles  were  then  displayed  on  a  VGA 
monitor.  For  any  tile  additions  required  for  display  updates,  a  new  "image 
palette"  would  have  to  be  created  in  order  to  obtain  accurate  color 
representations  for  ail  the  map  tiles. 

VIII.  RESULTS 

The  results  of  this  study  reveal  several  important  points  regarding 
compressed  database  preparation /display  and  image  quality  versus 
compression  ratios  achieved. 

As  evidence  from  this  study,  it  is  possible  to  produce  compressed  map 
databases  with  a  minimal  amount  of  hardware.  In  fact,  the  only  specialized 
equipment  needed  was  the  actual  compression/decompression  board.  By 
implementing  database  preparation  on  such  a  simple  system,  two  important 
objectives  are  met.  The  first  objective  is  to  produce  a  database  preparation 
system  that  is  low  cost.  A  complete  ADRG  database  compression  system 
should  cost  no  more  than  $10,000  including  the  compression /decompression 
card.  The  second  objective  is  to  maintain  compatibility  with  available  systems. 
Because  the  entire  ADRG  database  preparation  system  runs  on  an  MS-DOS 
based  PC,  all  MS-DOS  systems  (with  proper  hardware)  should  be  able  to 
perform  ADRG  database  preparation  either  in  the  field  or  in  the  office. 

During  the  course  of  this  study  various  quantization  factors  were 
examined  in  order  to  determine  their  effect  on  compression  ratios.  By  doing 
this,  we  were  able  to  ascertain  the  compression  levels  that  could  typically  be 
expected  on  ADRG  data.  Figure  6  shows  various  quantization  factors  and  the 
actual  compression  ratio  achieved  using  that  factor.  These  compression 
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Figure  6.  ADRG  Compression  Ratios  vs.  Quantization  Factors 

ratios  by  no  means  represent  the  level  of  compression  that  will  be  achieved  for 
all  ADRG  database  compression.  It  is  simply  a  gauge  of  the  levels  that  one 
might  expect  after  compressing  an  ADRG  database.  Results  show  that  the 
highest  quantization  factor  (Q  =  255),  produces  compression  ratios  of 
approximately  25: 1.  More  realistic  compression  ratios  (from  a  visual 
standpoint)  of  approximately  20: 1  are  obtainable  using  quantization  factors 
ranging  from  Q  =  140  through  Q  =  170.  Images  compressed  using  quantization 
factors  below  100  yield  lower  compression  ratios  but  better  quality  images. 

When  discussing  image  compression,  another  very  important 
consideration  that  must  be  addressed  is  the  issue  of  compression  ratio  versus 
image  quality.  This  is  a  very  difficult  and  highly  subjective  issue  to  discuss. 

An  image  that  may  appear  pleasing  to  one  individual  may  appear  unacceptable 
to  another.  Although  JPEG  is  designed  to  reduce  visually  redundant 
information  so  as  to  be  less  perceivable  to  the  human  eye,  when  compression 
ratios  are  increased  to  a  high  enough  level,  visual  distortions  begin  to  appear. 
The  question  then  becomes  how  much  distortion  is  too  much?  No  quantitative 
measurement  was  located  that  can  state  how  much  visual  degradation  is  too 
much  for  an  individual.  It  is  purely  a  subjective  decision.  Figure  7  shows  a 
map  section  that  has  not  been  compressed.  Compare  this  to  Figure  8  which 
shows  the  same  map  section  after  being  compressed  using  a  quantization 
factor  of  2  (compression  ratio  *  2.9:1).  Next  compare  these  figures  with  Figure 
9  which  has  been  compressed  using  a  quantization  factor  of  160  (compression 
ratio  =  19.8:1).  Finally,  Figure  10  shows  the  same  image  after  it  has  been 
compressed  using  the  maximum  quantization  factor  of  255  (compression  ratio 
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=  24.1:1).  Clearly,  as  the  quantization  factor  increases,  the  visual  degradation 
of  the  image  increases. 

DC.  CONCLUSIONS 

This  study  has  shown  that  image  compression  is  certainly  a  vety  useful 
tool  in  managing  the  size  of  huge  image  databases.  Using  JPEG  compression 
techniques  can  result  in  images  being  compressed  at  ratios  of  approximately 
20: 1  while  still  maintaining  good  visual  quality.  This 
compression/ decompression  can  also  be  done  in  a  timely  manner  due  to 
chips/ chipsets  currently  available.  This  is  important  to  systems  that  have 
stringent  timing  requirements. 

This  study  has  also  shown  that  database  preparation  systems  can  be 
both  inexpensive  and  easily  implemented  using  common  MS-DOS  based  PCs 
and  an  image  compression/ decompression  card. 
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APPENDIX  A 


CODE  TO  REFORMAT  ADRG  DATA 

//include  <stdio.h> 

//include  <conio.h> 

//include  <stdlib.h> 

//include  <dos.h> 

//include  <fcntl  .h> 

//include  <sys\stat.h> 

//include  <io.h> 

//include  <niath.h> 

//include  <errno.h> 

//define  true  1 
//define  false  0 

char  red_buff [16384]: 

char  *red_buff_ptr  -  red_buff: 

char  green_buff[16384] ; 

char  *green_buff_ptr  -  green_buff: 

char  blue_buff[16384]: 

char  *blue_buff_ptr  •  blue_buff; 

char  adrg_1mg_f1 le[13] : 

char  adrg_gen_file[13]; 

char  path_nan\e[283: 

static  char  long_ul[ll]; 

static  char  lat_u1[10]: 

void  mainC ) 

{ 

static  unsigned  long  Asz,  Bs; 

static  unsigned  long  NUL.  NUS.  NLL.  NLS: 

char  *buffer_ptr: 

static  unsigned  int  image_hei ght .  image_width: 

static  char  cen_natne[13] ; 

static  int  cnt; 

static  int  read_handle; 

static  int  read_handle_img: 

static  int  wri te_handl e ; 

unsigned  liit  "index  **  16384: 

char  buffer; 

static  char  row_nuni[3]: 

static  char  col_num[3]; 

char  user_response[l] ; 

static  int  i  -  0: 

static  int  j  -  0; 

int  1 nval id_response  -  true: 

/*  This  portion  of  the  code  prompts  the  user  for  input  regarding  the  name  */ 
/*  of  the  ADRG  General  Information  File  and  the  path  of  the  file.  The  */ 

/*  code  also  prompts  the  user  for  verification  of  input.  */ 

whi 1e( inval 1d_response  —  true){ 
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cl rscr( ) : 

printfCName  of  AORG  General  Information  File  { f  1 1  ename .  ext ) :  ’); 
gets(aclrg_gen_fi  le) ; 

printf(*Is  (%s)  Correct?  (Y  or  N);  *,  adrg_gen_f 1 1 e ) : 
gets(user_response) : 

i f ( (user_response[0]  --  'Y')  ||  ( user_response[0]  --  ‘y')){ 
printf(*Input  Path  Name  (d :  WpathnameW ) :  *): 
gets(path_name) : 

printfCIs  (Ss)  Correct?  (Y  or  N):  path_name): 

gets(user_response) : 

i f ( ( user_response[0]  —  ’Y')  {|  (user_response[0]  --  'y')) 
inval id_response  -  false; 

) 

) 


I*  Combine  the  path  with  the  General  Information  File  name  and  open  the  */ 
/*  file.  Discard  the  first  1777  bytes  of  information  in  the  file.  These  */ 
/*  bytes  may  be  useful  to  some  applications.  Consult  the  ADRG  Product  */ 
/*  Specification  for  more  information.  */ 


i  -  0: 

whil e( path_name[i ]  !-  'VO') 
i++: 

for(j  -  0;  adrg_gen_fi1e[j]  !-  ‘\0':  j++) 
path_name[i++]  -  adrg_gen_file[j]; 
path_name[i ]  -  ' \0' ; 

buffer_ptr  -  Sbuffer; 

read.handle  -  open(path_name,  0_R0ONLY  |  0_BINARY): 
read(read_hand1e.  buffer_ptr.  1777); 

/*  Read  the  8  bytes  that  represent  the  east-west  pixel  spacing  and  convert  */ 
/*  that  value  to  a  long  (Asz).  */ 

buffer_ptr  -  &Asz; 
read(read_handle.  buffer_ptr.  8); 

Asz  -  atol ( buf fer_ptr ) ; 

/*  Read  the  8  bytes  that  represent  the  north-south  pixel  spacing  and  */ 

/*  convert  that  value  to  a  long  (Bs).  */ 

buffer_ptr  -  &Bs: 
read( read_handl e .  buffer_ptr,  8): 

Bs  -  atol (buf fer_ptr) : 


/*  Read  the  11  bytes  that  represent  the  longitudinal  coordinates  of  the  */ 

/*  upper  left  corner  of  the  area  of  coverage  into  the  long_ul  array.  The  */ 

/*  format  is  +/-  DDDMMSS.SS.  */ 

buffer_ptr  -  &long_u1: 
read(read_handle.  buffer_ptr,  11); 

Read  the  10  bytes  that  represent  the  latitudinal  coordinates  of  the  */ 

/*  upper  left  corner  of  the  area  of  coverage  into  the  lat_u1  array.  The  */ 

/*  format  is  +/-  DDMMSS.SS.  */ 

buffer_ptr  -  &lat_ul: 
read( read_handl e .  buffer_ptr.  10); 
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/*  Read  and  discard  the  next  65  bytes.  These  bytes  may  useful  to  some  */ 

/*  applications  so  code  modification  may  be  necessary.  */ 

buffer_ptr  -  &buffer; 
read( read_handle .  buf fer_ptr ,66) ; 

/*  Read  the  6  bytes  that  represent  the  row  number  of  the  upper  right  */ 

/*  corner  of  image  data  (NUL).  The  value  is  then  converted  to  a  long.  */ 

buffer_ptr  -  &NUL; 
read( read_hand1 e ,  buffer_ptr,  6); 

NUL  -  atol ( buffer_ptr ) : 

/*  Read  the  6  bytes  that  represent  the  column  number  of  the  upper  right  */ 

t*  corner  of  image  data  (NUS).  The  value  is  then  converted  to  a  long.  */ 

buffer_ptr  -  &NUS; 
read(read_handle,  buffer_ptr.  6): 

NUS  “  atol (buffer_ptr ) : 

/*  Read  the  6  bytes  that  represent  the  row  number  of  the  lower  left  */ 

/*  corner  of  ■'mage  data  (NLL).  The  value  is  then  converted  to  a  long.  */ 

buffer_ptr  -  &NLL; 
read(read_handle,  buffer_ptr,  6): 

NLL  -  atol (buffer_ptr ) ; 

/*  Read  the  6  bytes  that  represent  the  column  number  of  the  lower  left  */ 
/*  corner  of  Image  data  (NLS).  The  value  Is  then  converted  to  a  long.  */ 
buffer_ptr  -  &NLS; 
read(read_handle.  buffer_ptr,  6): 

NLS  -  atol (buffer_ptr ) : 

/*  Read  the  3  bytes  that  represent  the  height  of  the  map  image  (in  128x128  */ 
!*  pixel  tiles).  The  value  is  then  converted  to  an  integer.  */ 

buffer_ptr  -  &lmage_he1ght: 
read(read_hand1 e .  buffer_ptr,  3): 
image_height  -  atoi (buffer_ptr ) ; 

/*  Read  the  3  bytes  that  represent  the  width  of  the  map  image  (in  128x128  */ 

/*  pixel  tiles).  The  value  is  then  converted  to  an  integer.  */ 

buffer_ptr  »  &image_width ; 
read(read_handle,  buffer_ptr,  3): 
image_width  -  atoi ( buffer_ptr ) : 

/*  Read  and  discard  the  next  17  bytes.  These  bytes  may  useful  to  some  */ 

/*  applications  so  code  modification  may  be  necessary.  */ 

buffer_ptr  -  &buffer; 
read(read_hand1e.  buffer_ptr,  17); 

/*  Read  the  12  bytes  that  represent  the  name  of  the  ADRG  Image  File.  The  */ 
/*  bytes  are  stored  in  the  adrg_img_fne  array.  */ 

buffer_ptr  -  &adrg_img_f i le; 
read(read_handle.  buffer_ptr,  12): 

7*  Read  and  discard  the  next  77  bytes.  These  bytes  may  useful  to  some  */ 

/*  applications  so  code  modification  may  be  necessary.  *! 

buffer_ptr  -  &buffer; 
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read(reacl_han(ne.  buffer_ptr.  77); 


/*  Open  the  ADRG  image  file  and  strip  out  unused  header  bytes.  Color  */ 
I*  tile  information  is  then  stored  for  reformatting  process.  */ 

i  -  12: 

forCj  -  0:  adrg_img_fileCj]  !-  '\0‘:  j-M-) 
path_name[i++3  -  adrg_img_fi 1 e[ j ] : 

read_handl e_img  -  open< path_name .  0_RD0NLY  |  0_BINARY); 
read(read_handle_img.  buffer_ptr.  2048); 
j  -  0: 
i  -  0: 

printfCVn-): 


j  it  it  it  if  it  it  ■k'k  it  it  it  it  it 'it  ■kitit  it  if  ^  it  if  it  it  ■kit  it  •it  ^  it  It  it  it  It  it  it  it  it  it  it  it 'kit  it  it  it  it  it  it it  ^  it  it  it  if  it  it  it  ^  it  it  it  if  it  j 


/*  This  is  the  loop  that  names  and  reformats  every  image  tile  in  every  */ 
I*  row.  The  image_height  and  image_width  variables  are  used  to  keep  track  */ 
/*  of  this  loop.  Tiles  are  named  with  the  following  convention:  */ 
/*  */ 
/*  TILE  NOMENCLATURE  -  ODD  dd  RRR.CCC  */ 
/*  */ 
/*  ODD  -  Longitude  (degrees)  of  the  upper  left  map  corner  */ 
/*  dd  -  Latitude  (degrees)  of  the  upper  left  map  corner  */ 
/*  RRR  -  Map  tile  row  number  */ 
/*  CCC  •  Map  tile  column  number  *! 


^ ******************************************************************* ********  j 

ford  -  0;  (i  <  image_height);  i++){ 
for(j  -  0;  j  <  image_width:  j++){ 


for(cnt  -  0;  cnt  <  3;  cnt++) 

cel l_name[cnt]  •  long_ul[cnt  +  1]; 
for(cnt  -  3;  cnt  <  5:  cnt++) 

cel l_name[cnt]  -  lat_ul[cnt  -  2]; 
Itoad,  row_num,  10); 
ifd  <-  9){ 

cel l_name[5]  -  'O' ; 
cell_name[6]  -  'O' ; 
cell_name[7]  -  row_num[0]; 


else  ifd  <-  99 ){ 

cel l_name[5]  -  'O' ; 
cell_name[6]  -  row_num[0]; 
cell_name[7]  -  row_num[l]: 

) 

else! 

for(cnt  -  5;  cnt  <  8;  cnt++) 
cel l_name[cnt]  -  row_num[cnt  -  5]; 

) 

cel l_name[8]  -  ' . ' ; 
itoa(j.  col_num.  10); 
if(J  <-  9){ 

cel l_name[93  -  'O' ; 

cell_name[10]  -  'O' ; 

cel l_nametll 3  -  col_numC03: 
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) 

else  if(j  <-  99){ 
cel  1_naine[9]  -  'O' : 
cel l_nameC10]  -  col_numC03: 
cel l_nametll ]  ■  co1_num[l]: 

) 

el  se{ 

for(cnt  -  9:  cnt  <  12;  cnt++) 
cel l_name[cnt]  -  col_num[cnt  -  9]; 

} 

cel1_name[12]  -  '\0'; 
index  -  16384; 

prIntfCNow  formatting  fs\n  *.  cen_name); 

/*  This  section  reads  the  data  from  the  Image  tile  Into  3  buffers.  These  */ 
/*  are  the  red.  green,  and  blue  color  byte  buffers  for  each  tile.  */ 

write_handle  -  open(cel l_name.  0_CREAT  |  0_BINARY.  S_IREAD 
I  S_IWRITE): 

read(read_handle_1mg,  red_buff_ptr ,  index): 
read(read_handle,img.  green_buff_ptr .  index); 
read( read_hand1e_1mg.  blue_buff_ptr,  index); 

/*  Create  files  for  the  128x128  pixel  blocks.  Pixels  are  then  written  to  */ 
/*  a  file  in  the  format  R-byte,  G-byte,  B-byte  until  all  128x128x24  pixel  *! 
/*  values  have  been  written.  */ 

for( index  -  0;  index  <  16384;  index++){ 
wr1te(wr1te_handle.  red_buff_ptr++.  i); 
wr1te(write_handle.  green_buff_ptr++.  1); 
wr1te(write_handle.  blue_buff_ptr-M-,  1); 

) 

red_buff_ptr  -  &red_buff; 
green_buff_ptr  -  &green_buff: 
bl ue_buff_ptr  -  &blue_buff: 
close(wrl te_handle) ; 

} 

} 

close(read_handle) ; 
close(read_handle_img); 
return(O) ; 

} 


19 


CODE  TO  COMPRESS  ADRG  DATA 


^include  <stdio.h> 

#include  <conio.h> 

#1nc1ude  <std11b.h> 

^include  <dos.h> 

#inc1ude  <fcnt1 .h> 

^include  <sys\stat.h> 

#1  .lude  <sys\types . h> 

^include  <1o.h> 

^include  <math.h> 

#1nclude  <errno.h> 

//include  <toolapp.h> 

//include  <l_error.h> 

//include  <l_bitmap.h> 

//define  true  1 
//define  false  0 

/*  Increase  the  size  of  the  stack.  */ 

extern  unsigned  _stklen  -  14000U: 

void  main/ ) 

{ 

BITMAPHANDLE  ADRG.Bitmap; 
int  Q_factor: 

unsigned  int  image_height  -  71; 

unsigned  int  image_width  -  107; 

static  char  long_ul[ll]; 

static  char  lat_ul[10]: 

char  row_num[3]; 

char  col_num[3]: 

static  char  cel l_name[15] ; 

static  int  i ,  j .  cnt; 

int  read_handle; 

unsigned  char  *pBuf; 

int  ret_val: 

char  user_response[5] : 

int  inval id_response  -  true; 

char  f11e_pref1x[5] : 

/*  Prompt  the  user  for  the  longitude  and  latitude  of  the  upper  left  map  */ 

/*  corner,  the  file  prefix  (for  naming  purposes),  and  the  Q  factor  to  be  */ 

/*  used  for  compression.  */ 

whi 1 e( inval 1d_response  —  true)! 
cl rscr( ) : 

printfCInput  Longitude  of  the  Upper  Left  Corner  (ODD):  '); 
gets(long_ul ); 

printfCInput  Latitude  of  the  upper  left  corner  (dd):  *): 
gets(1at_u1 ) : 

pr1ntf( ’Input  File  Prefix  (A-Z):  ’); 
gets(f i 1 e_pref1 x ) : 

printf (’Input  Q  Factor  for  File  Compression  (1-255):  ’): 
gets(user_response) : 
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Q_factor  -  atoi (user_response> : 

printfC’Is  id  Correct?  (Y  or  N);  *.  Q_factor): 

gets(user_response) ; 

i f ( (user_responsetO]  —  'Y')  j]  ( user_response[0]  —  ‘y’)) 
tnval id_response  -  false: 

) 

/*  Compress  files  within  the  boundaries  given  by  the  map  image  height  and  */ 
/*  width.  */ 

ford  -  0;  1  <  image_he1ght:  i++){ 
for(j  “  0:  j  <  image_width;  j++)( 

/*  Create  the  name  of  the  file  to  be  compressed  using  the  user  input  for  */ 

/*  upper  left  longitude  {long_ul)  and  upper  left  latitude  (lat_ul). 
forCcnt  -  0:  cnt  <  3;  cnt-H-) 

cel l_name[cnt]  -  long_ul [cnt] : 
for(cnt  -  3:  cnt  <  5;  cnt++) 

cel l_name[cnt]  -  lat_ul[cnt  -  3]; 

/*  Convert  image  row  index  (1)  to  a  string  and  store  it  in  the  row_num  */ 

/*  array  for  use  in  generating  a  file  name.  As  the  row  number  is  */ 

/*  incremented,  the  ce11_name  will  be  incremented  accordingly.  */ 

itoad.  row_num,  10): 
ifd  <-  9){ 

cel l_nameC5]  -  'O' : 
cel l_name[6]  -  *0' ; 
cel1_name[7]  -  row_^num[0]: 

) 

else  ifd  <-  99){ 
cell_name[5]  -  'O' ; 
cel1_name[6]  -  row_num[0]: 
cell_name[7]  -  row_num[l]; 

) 

el  se{ 

for(cnt  -  5;  cnt  <  8:  cnt++) 
cel l_name[cnt]  -  row_num[cnt  -  6]: 

) 

cel l_nameC8]  -  ‘ ; 

/*  Convert  image  column  index  (j)  to  a  string  and  store  it  in  the  col_num  */ 
I*  array  for  use  in  generating  a  file  name.  As  the  column  number  is  */ 

/*  incremented,  the  ce11_name  will  be  incremented  accordingly.  */ 

1toa(j,  col_num.  10): 
if(j  <-  9){ 

cel l_name[9]  -  ' 0' : 

cell_name[10]  -  'O’ ; 

cel l_name[ll]  -  col_num[0]; 

) 

else  1 f ( j  <-  99) { 
cel l_name[9]  -  ' 0’ : 
cel l_name[10]  -  col_num[0]; 
cell_name[ll]  -  col_numCl]: 

) 

el  se{ 
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for(cnt  -  9;  cnt  <  12;  cnt++) 
cel l_name[cnt]  -  col^numTcnt  -  9]; 

} 

/*  Close  cell_name  array  with  the  end-of -string  character  ’XO’.  */ 

cel l_name[ 12]  “  ' \0 ' ; 

/*  Initialize  and  allocate  space  (in  expanded  memory)  for  a  128x128  pixel  */ 
/*  (24  bi t -per -pi xel )  image  bitmap.  */ 

L_Ini tBi tmapi &ADRG_Bi tmap,  128,  128.  24); 

L_A1 1 ocateBi tmap(SADRG_Bi tmap,  TYP£_NOCONV ) ; 

/*  Open  the  map  file  and  load  each  pixel  row  into  the  bitmap  using  the 
/*  L_PutBitfflapRow  call.  If  no  file  exists  (read.handle  <  0)  then  exit  the  •/ 
/*  loop. 

i f ( ( read_handl e  -  open(cel 1_name.  0_RD0NLY  j  0_B1NARY))  >  0)( 
for(cnt  -  0;  cnt  <  128:  cnt++){ 
read( read_handl e ,  pBuf.  384): 

L_PutBi tmapRow(&AORG_Bi tmap,  pBuf.  cnt.  384); 

) 

/•  Close  the  file. 

cl  ose( read_handl e ) ; 

/*  Insert  the  file  prefix  into  the  first  position  of  the  cell_name  array.  */ 
/*  Compress  the  image  and  report  whether  the  compression  was  successful.  */ 

cell_name[0]  -  f1 1 e_pref1x[0] : 

ret_val  -  L_CompressB1  tmap( JADRG_B1  cen_name,  JFIF, 

0_factor.  NoVGAPalette) : 
if(ret_val  —  SUCCESS) 

printfC "Compression  on  file  %s  was  a  successXn".  cell_name): 
else 

printfC’Error  #%d  occurredXn*.  ret_val): 

) 

el  se 

printfCUnable  to  Open  File  %s\n'.  ce1l_name); 

/*  Free  the  bitmap  using  L_FreeB1tmap  and  begin  compression  on  the  next  */ 
/*  fi 1e.  */ 

L_FreeBi tmap{&ADRG_Bi tmap ) ; 

I 

} 

) 
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CODE  TO  DECOMPRESS  AND  DISPLAY  ADRG  DATA 


#inc1ude 
#incl ude 
tfincl ude 
#iiic1ude 
ncl ude 
#inc1 ude 
#include 
#i ncl ude 
#1 ncl ude 
#incl ude 
#1nclude 
#1nc1 ude 
#i ncl ude 
//include 


<stdio.h> 
<coni 0 . h> 
<stdl 1b. h> 
<dos.h> 

<f cntl . h> 
<sys\stat . b> 
<i 0 . h> 

<math . h> 
<errno . h> 
<graphl cs . h> 
<al  1  oc .  u', 
<toolapp.h> 

< !_error . n> 
<l_bltmap. h> 


//define  true  i 
//define  false  0 


/*  Increase  the  sl2e  of  the  stack, 
extern  unsigned  _stklen  -  14000U: 

void  mainO 
( 

BITMAPHANOLE  ADRG.BI tmap.  New256_Co1or .  New_Palette.  Old.Palette  : 

char  row_num[5]: 

char  disp1ay_tile[15]: 

char  dcom_t11e[15] : 

unsigned  int  cnt: 

unsigned  int  index: 

signed  j ,  1 : 

int  read_handle.  write_handle; 

Int  x_coord; 

int  y_coord; 

char  pixe1_color: 

char  center_t1 1 e[l5] : 

int  inval id_response  -  true: 

char  user_response[ 10] : 

signed  int  tile_row_cnt: 

signed  int  ti 1 e_co1_cnt : 

int  x_center  -  256; 

int  y_center  -  176; 

signed  int  itnage_width  -  107: 

signed  int  image_he1ght  -  71: 

unsigned  char  pBuf_array[128] ; 

unsigned  char  *pBuf  -  p8uf_array: 

unsigned  char  new_pBuf_array[256] ; 

unsigned  char  *new_pBuf  -  new_pBuf_array ; 

unsigned  char  pRow_array [768] ; 

unsigned  char  *pRow  -  pRow_array; 

char  col_num[5]; 
int  ret_va1 : 
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unsigned  Int  display_cnt; 
unsigned  Int  p_row_cnt  -  0; 

char  far  *fptr: 
unsigned  long  mem_si2e; 
unsigned  char  color_index; 
int  mode,  page: 

char  f i rst_char[l ] : 

/*  Store  current  video  mode.  */ 

L_GetVideoMode(&mode ,  &page): 

/*  Prompt  and  verify  the  user  for  the  center  tile  image  to  be  displayed.  */ 
whne(inva1id_response  --  true){ 
cl rscr( ) : 

printfCInput  Center  Tile  ( LonLtRow.Col ) :  ’); 
gets(center_ti le) : 

pr1ntf(*Is  %s  Correct?  (Y  or  N):  center_tne); 

gets(user_response) : 

i f( (user_response[03  —  'Y')  ||  (user_response[0]  —  'y')) 
inval id_response  -  false: 

) 

/*  Create  a  file  for  storage  of  color  palettes.  */ 

write_handle  -  openCPalette.mwc'.  0_CREAT  |  0_BINARY  |  0_RDWR.  S_IREAD  | 
S.IWRITE); 

/*  Extract  row  and  column  Information  from  the  center  tile  name.  */ 

fordndex  -  5;  Index  <  8;  1ndex++) 
row_num[index  -  5]  -  center_ti letlndex]; 
fordndex  -  9;  index  <  12:  index++) 
col_num[index  -  9]  -  center_t1 1 eCindex] : 
ti1e_row_cnt  -  atoi ( row_num) ; 
tile_col_cnt  -  atoi (col_num) : 


/*  Remove  the  file  prefix  and  replace  with  the  original  0  found  in  the  */ 
/*  longitudinal  value  of  the  upper  left  map  corner.  */ 

f 1 rst_ch3r[0]  -  center_ti 1 e[0] : 
center_ti le[03  -  0: 

/*  Load  the  display_tile  array  with  the  longitudinal  and  latitudinal  */ 

/*  values  that  make-up  the  center_tile  name.  */ 

fordndex  -  0:  Index  <  5:  index-^-^) 
di spl ay_ti 1 e[index3  -  center_ti le[index3 : 

/*  This  loop  is  used  to  display  a  5x5  matrix  of  tiles  that  will  be  */ 

/*  centered  around  the  tile  input  by  the  user.  The  first  tile  processed  */ 

/*  is  in  the  upper  left  of  the  image.  The  tiles  along  that  row  are  then  */ 

/*  processed  sequentially  and  the  next  row  is  then  processed  starting  from  */ 

/*  the  left  side  and  working  right.  */ 

ford  -  tile_row_cnt  -  2:  i  <-  t1le_row_cnt  +  2:  i++)( 
itoad.  row_num.  10): 

1f(d  <  0)  I  I  (1  >-  image_height)){ 
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forCIndex  -  5;  Index  <  8;  index-*-*-) 
display_t11e[index]  -  •?': 

) 

else  if(1  <-  9){ 

d1splay_ti le[5]  -  ‘O' : 
d1 sp1ay_ti 1e[6]  -  '0 ‘ ; 
display__tne[73  -  row_num[0]; 

} 

else  1f(i  <-  99){ 

di sp1ay_ti le[5]  -  'O' : 
display_ti1e[6]  -  row_num[03: 
di splay_ti 1e[73  -  row_num[13: 

} 

el  se{ 

for(cnt  -  5:  cnt  <  8;  cnt-*-*-) 

d1splay_t11e[cnt3  -  row_num[cnt  -  53: 

) 

for(j  -  tile_col_cnt  •  2:  j  <-  tne_col_cnt  2:  j-*--*-)! 

1toa(j.  col_num.  10): 
d1splay_ti le[83  -  ' . ‘ : 

/*  If  the  tile  Is  out  of  bounds  (1e.  the  column  number  Is  less  than  0  and  */ 
/*  greater  than  the  1mage_width)  a  '?'  Is  loaded  into  the  file  name  so  as  */ 
/*  to  produce  a  nonexistent  tile  name  that  will  not  be  displayed.  •/ 

1f((j  <  0)  II  (J  >-  1mage_w1dth)){ 
fordndex  -  9;  Index  <  12:  Index-*-*-) 
display_t11e[1ndex3  - 

} 

else  1 f ( j  <-  9) { 

display_tile[93  -  'O' ; 
d1splay_t1le[l03  -  'O': 
d1splay_t11e[ll]  -  col_num[03; 

} 

else  1f(j  <-  99){ 

display_tile[93  -  'O' : 
display_t11e[103  -  col_num[03: 
d1splay_t1 le[113  ■  col_num[13; 

) 

el  se{ 

forCcnt  “  9:  cnt  <  12;  cnt-*-*-) 
d1splay_t1le[cnt3  •  col_num[cnt  -  93: 

} 

/*  Close  cell_name  array  with  the  end-of -string  character  ’\0‘.  */ 

d1splay_t11e[123  -  '\0': 

/*  Load  the  dcom_t11e  array  with  the  display.tlle  array.  */ 

for(cnt  -  0;  cnt  <  13;  cnt-*-*-) 

dcom_t1 le[cnt]  -  d1splay_t11e[cnt3: 

/*  Add  the  file  prefix  to  the  d1splay_t11e  array  In  position  [03  */ 

d1 spl 3y_t1 1e[03  -  f1 rst_char[03 : 
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/*  Initialize  a  bitmap  of  128x128  pixels  and  24-bit  color  */ 

L_Initeitmap(&ADRG_Bitmap.  128,  128.  24); 

/*  Decompress  the  disp1ay_tile  and  store  it  in  the  bitmap  •/ 

printfC  ‘Decompression  on  tile  2s',  display_tile  )  : 
ret_val  -  L_DecompressB1 tmapldi splay_t i 1 e ,  &ADRG_B1 tmap.  BIT24); 

/*  If  decompression  was  successful,  optimize  the  image  from  24-bit  color  */ 

/*  down  to  8-bit  color.  If  successful,  write  the  8-bit  palette  to  the  */ 

/*  file  ' Palette .mwc ' .  */ 

if(  ret_val  —  SUCCESS  ){ 

ret_val  -  L_OptimizeB1tmap(&ADRG_Bitmap.  &New256_Col or . 

NO_DITHERING,  256); 

L_FreeBitmap(&A0RG_81 tmap) : 
printfC  *  SUCCEEOEO!\n‘  )  ; 

} 

el  se 

printfC  ■  FAlLED!\n*  )  : 

/*  Check  for  the  proper  number  of  colors  written  to  the  ’ Pal ette .mwc ’  file.*/ 
ifC  wri teCwri te^handl e ,  New256_Color.pPalette.  768)  !-  768  ){ 
printfC  ‘Error  writing  768  bytes!\n‘  )  : 

) 

/*  Free  the  bitmap.  */ 

L_FreeBi tmap C&New256_Co lor ) ; 

) 

} 


/*  Close  the  file  'Palette. mwc' .  */ 

cl oseCwri te_handle) ; 

/*  Initialize  and  allocate  memory  for  a  bitmap.  */ 

L_InitBitmapC&01d_Palette.  256.  25.  24); 
ret_val  -  L_A1 1 ocateBi tmapC&01d_Palette ,  TYPE_NOCONV) ; 

/*  Open  the  'Palette. mwc’  file.  */ 

read_handle  -  openC 'Pal ette .mwc* .  0_RD0NLY  |  0_BINARY.  S_IREA0): 

/*  Place  all  25  palettes  C5x5  tiles)  into  the  newly  allocated  bitmap  */ 


forCcnt  -  0;  cnt  <  25;  cnt+-t-)( 
ret_val  -  readC read_handl e.  pRow,  768); 
ret_val  -  L_Put8i tmapRowC&01d_Palette.  pRow.  cnt.  768): 

} 


/*  Close  the  'Palette. mwc’  file.  */ 

closeCread_handle) ; 

/*  Change  the  color  byte  order  from  RGB  to  BGR.  */ 

01d_Pal ette . Order  -  0RDER_BGR; 

/*  Optimize  the  palette  file  ' Pal ette .mwc '  so  as  to  produce  the  best  256  */ 

/*  colors  for  all  the  Images.  */ 


ret_val  -  L_0ptim1zeBitmapC&01d_Palette.  &New_Pal ette.  NO_OITHFRING. 
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256): 


/*  Free  the  0)cl_Palette  bitmap.  */ 

L_FreeBi tmap(&0)d_Pa1ette) : 

/*  Set  display  resolution  for  the  map  image  to  640x480.  •/ 

L_SetVGASize(  SIZE_640x480  ): 

/*  Extract  row  and  column  Information  from  the  center  tile  name.  •/ 

fordndex  -  5:  index  <  8;  1ndex++) 
row_num[1ndex  -  5]  -  center_ti leCIndex] : 
fordndex  -  9;  index  <  12;  index++) 
co1_num[ i nopx  -  9]  -  center_tne[1ndex] ; 
tile_row_cnt  -  atoi (row_num) : 
t1le_col_cnt  -  atoi (col_num) : 


/*  Load  the  display_tile  array  with  the  longitudinal  and  latitudinal  */ 

/*  values  that  make-up  the  center_t11e  name.  */ 

fordndex  -  0;  index  <  5;  index++) 
display_t1 lefindex]  -  center_t1 1e[1ndex] : 

/*  This  loop  is  used  to  display  a  5x6  matrix  of  tiles  that  will  be  */ 

/*  centered  around  the  tile  input  by  the  user.  The  first  tile  processed  */ 

/*  is  in  the  upper  left  of  the  image.  The  tiles  along  that  row  are  then  */ 

/*  processed  sequentially  and  the  next  row  is  then  processed  starting  from  */ 

/*  the  left  side  and  working  right.  */ 


ford  -  tile_row_cnt  -  2;  1  <-  tile_row_cnt  +  2;  1++){ 
itoad,  row_num.  10): 

1f(d  <  0)  II  d  >  image_height)){ 
fordndex  -  5;  index  <  8:  index-M-) 
displ3y_t11e[1ndex]  -  ’?•; 

) 

else  1 f  d  <-  9 )  { 

di spl ay_ti le[5]  -  'O’ : 
d1splay_tile[6]  -  'O' ; 
di splay_ti le[7]  -  row_num[0]; 

) 

else  ifd  <-  99)( 

di splay_ti le[5]  -  ‘ O' : 
di sp1ay_tnet6]  -  row_num[0]; 
di spl ay_ti 1 e[7]  -  row_num[l]: 

} 

el  se  ( 

for(cnt  -  5;  cnt  <  8;  cnt-*"*-) 

di spl ay_t1 1 eCcnt]  -  row_num[cnt  -  5]: 

) 

/*  If  the  tile  is  out  of  bounds  (ie.  the  column  number  is  less  than  0  and  */ 
/*  greater  than  the  image_w1dth)  a  ’?'  is  loaded  into  the  file  name  so  as  */ 
/*  to  produce  a  nonexistent  tile  name  that  will  not  be  displayed.  */ 

for(j  -  tile_col_cnt  -  2;  j  <-  tile_col_cnt  +  2:  :+•+){ 
itoaCj,  col_num.  10): 
di sp1ay_ti 1 e[8]  -  ’ . ' ; 

1f((j  <  0)  jj  (j  >-  1mage_width)){ 
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fordndex  -  9:  index  <  12;  index++) 
display_t1'le[index]  -  '?*; 

I 

else  if(j  <-  9){ 

disp1ay_tile[9]  -  ‘O' ; 
cJisplay_tne[10]  -  'O' ; 
display_tile[ll]  -  co1_num[0]: 

} 

else  if(j  <-  99 ){ 

di splay_tne[9]  -  ' O' : 
d1splay_t1 1e[10]  -  col_num[0]; 
display_tile[ll]  -  co1_numCl]: 

) 

else{ 

forCcnt  -  9;  cnt  <  12;  cnt++) 
d1splay_tne[cnt]  -  co1_numtcnt  -  9]; 

) 

di spl ay_ti 1 e[12]  -  '\0'; 

for(cnt  -  0;  cnt  <  13:  cnt++) 

dcom_ti 1 e[cnt]  -  d1splay_tile[cnt]: 

/*  Close  cel1_name  array  with  the  end-of -string  character  ’\0'.  */ 

d1splay_tne[0]  -  f i rst_char[0] ; 

/*  Initialize  a  bitmap.  */ 

L_InttB1tm3p(iADRG_81tmap.  128.  128.  24); 

/*  Decompress  the  map  tile  once  again  and  store  It  in  the  bitmap.  *! 

if((ret_val  -  L_DecompressB1 tmap(  d1splay_tne,  &ADRG_B1 tmap. 

BIT24))  <-0)( 

printfC “Decompression  on  file  Xs  failed.  Xd\n’,  dcom_t11e. 
ret_val ) ; 

) 

/*  Optimize  the  colors  of  the  decompressed  bitmap.  */ 

if(  ret.val  —  SUCCESS  ){ 

ret_val  -  L_0ptimizeBitmap(&A0RG_B1tmap.  &New256_Col or , 
NO_DITHERING.  256); 

L_FreeBi tmap(&ADRG_Bi tmap) : 


/*■  Load  the  optimized  image  palette  (from  'Palette. mwc' )  into  the  newly  */ 
/*  created  optimized  palette  for  the  image.  */ 

for(cnt  -  0;  cnt  <  768:  cnt-*-*-) 

New256_Co1or.pPalette[cnt]  -  New_Palette.pPalette[cnt]  : 

/*  Re-index  the  8-bit  map  data  to  the  updated  color  palette.  This  re-maps  */ 
/*  all  pixel  data  (128x128  pixels)  to  the  Image  palette.  */ 

L_GetBitmapRow(&New_P3lette.  new_pBuf,  p_row_cnt.  256): 
p_row_cnt-^"^; 

fordndex  -  0:  index  <  128:  Index-*--*-)! 

L_GetBitmapRow(&New256_Color,  pBuf.  Index,  128): 
for(cnt  -  0:  cnt  <  128;  cnt-^-*■)^ 
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color_1ndex  -  pBuf[cnt]: 
pBuf[cnt]  -  new_pBuf[color_index]: 

) 

L_PutB1 tmapRow(&New256_Co1or .  pBuf,  index.  128): 

) 

/*  Calculate  the  display  coordinates  for  each  tile  and  load  the  tile  to 
/*  the  screen.  Free  the  bitmap  after  each  tile  is  displayed. 
if(  ret_val  --  SUCCESS  ){ 

y_coord  -  y_center  +  ({tile_row_cnt  -  i)  *  128): 
x_coord  -  x_center  -  ( { t i 1 e_col_cnt  -  j)  *  128); 

New256_Col or . XOf f set  -  x_coord  ; 

New256_Color . YOffset  -  y_coord  : 

New256_Color . ViewPerspecti ve  -  BOTTOM_LEFT  ; 
L_ViewBitmapScreen(  &New256_Color ,  0.  0  )  : 

L_FreeBi tmap(&New256_Col or ) ; 

) 


/*  Free  the  optimized  image  color  palette. 

L_FreeBi tmap(&New_Palette ) ; 

/*  Wait  for  a  user  input  before  clearing  the  map  display. 
getcharO  ; 

/*  Reset  monitor  to  original  video  mode. 
L_SetVideoMode(mode,  page): 


} 
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APPENDIX  C 


KEY  TERMS 

ADRG: 

ARC  Digitized  Raster  Graphics 

BAUD; 

Bits  per  Second 

CCITT: 

Consultative  Committee  on  International  Telephony 

and  Telegraphy 

CD-ROM; 

Compact  Disk  Read-Only- Memory 

CMYK; 

Cyan,  Magenta,  Yellow,  Black 

DCT: 

Discrete  Cosine  Transform 

DIS: 

Draft  International  Standard 

DMA: 

Defense  Mapping  Agency 

EISA; 

Extended  Industry  Standard  Architecture 

FOG-M; 

Fiber-Optic  Guided  Missile 

IDCT; 

Inverse  Discrete  Cosine  Transform 

lEC; 

International  Electrotechnical  Commission 

IFCS: 

Improved  Fire  Control  System 

I/O: 

Input/Output 

ISA; 

Industry  Standard  Architecture 

ISO: 

International  Standards  Organization 

JPEG: 

Joint  Photographic  Experts  Group 

MLRS: 

Multiple  Launch  Rocket  System 

MPEG; 

Motion  Picture  Experts  Group 

MS-DOS: 

Microsoft  Disk  Operating  System 

PC: 

Personal  Computer 

Px64: 

CCITT  H.261  Standard  for  Video  Teleconferencing 

RGB: 

Red,  Green,  Blue 

SCSI: 

Small  Computer  System  Interface 

TRIS; 

Technical  Risk  Investigation  System 

UAV; 

Unmanned  Aerial  Vehicle 

UGV: 

Unmanned  Ground  Vehicle 

VGA: 

Video  Graphics  Adapter 

YUV: 

Luminance,  chrominance 
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APPENDIX  D 


COMPRESSION  HARDWARE  DIAGRAM 


EISA  BUS 


486  PC 

DECOMPRESSION  HARDWARE  DIAGRAM 


486  PC 
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